Support des GUID

La totalité ou presque des modules EMu sont capables d’utiliser les GUID. Les exceptions incluent :

• Trace d'audit (eaudit)
• Constats d'état (econdition)
• Définition de champs (efieldhelp)
• Index Géographique (egazetteer)
• Déplacements internes (einternal)
• Opérations (eoperations)
• Registre (eregistry)
• Statistiques (estatistics)
• Estimations (evaluations)

où l'utilisation de GUID est jugée inutile. Pour tous les modules compatibles avec les GUID, une table GUID s’affiche dans l’onglet Admin, permettant d’ajouter, de modifier, d’afficher, de rechercher et d’inclure des GUIDs dans les rapports :

Le tableau GUID comprend trois colonnes :

Champ	Valeur
Préféré	Oui / Non. Un seul GUID dans la table des GUID peut être marqué comme préféré.
Type	Liste de consultation des types de GUID.
GUID	Le GUID même. URLs Si le GUID est une URL, le bouton Afficher le document situé à côté de la grille des GUID est activé : Cliquez sur le bouton pour lancer l’application associée afin d’afficher le document.

Le tableau GUID peut contenir plusieurs identifiants générés en interne et en externe.

Les champs GUID sont également disponibles pour les requêtes en mode Requête :

EMu peut générer automatiquement les valeurs GUID lors de la sauvegarde des enregistrements. Actuellement, les GUID sont générés automatiquement en conformité avec UUID Version 4.

Par défaut, la génération automatique des GUID est désactivée pour tous les modules.

Pour activer la génération automatique des GUID dans un module (ou dans tout le système), les deux entrées de Registre GUID doivent être spécifiées :

• L’Entrée de Registre GUID Enabled doit être réglée sur true

  -ET-

• Une Entrée de Registre GUID Auto Types doit spécifier quel(s) type(s) de GUID générer pour un module (ou le système). Actuellement, seul UUID4 est supporté.

Lors de la sauvegarde, EMu vérifie si le tableau GUID inclut une entrée pour chaque type spécifié dans une Entrée de Registre GUID Auto Types, et génère un GUID pour chaque type qui est manquant.

Actuellement EMu génère automatiquement un GUID UUID Version 4 si un n’a pas déjà été ajouté au tableau GUID de l’enregistrement.

• Les organisations peuvent avoir besoin de considérer leur politique de suppression d’enregistrements qui contiennent des GUID générés localement. Une fois qu’un enregistrement a un GUID d’attribué, cet enregistrement devrait généralement ne jamais être supprimé. Notre préférence a toujours été que les enregistrements soient Retiré (en utilisant les paramètres Sécurité au niveau de l’enregistrement) plutôt que de les supprimer. Un enregistrement Retiré est caché pour tous les utilisateurs, sauf pour les personnes autorisées à le voir.
• La fusion d’enregistrements qui contiennent des GUID est un autre cas à considérer. Les organisations peuvent vouloir maintenir le ou les anciens GUID du ou des enregistrements fusionnés dans le tableau GUID de l’enregistrement maître (celui dans lequel la fusion a eu lieu).

Phase 3 of EMu GUID support will provide local resolution of GUIDs in formats that EMu recognizes.

Without a resolving service the GUID is simply an identifier providing little or no indication of the associated metadata. Some GUID formats, such as UUID, are completely opaque and provide no indication of the data associated with the GUID. Some industry bodies stress opaque identifiers are desirable and best practice, whereas others are more comfortable with non-opaque identifiers.

A GUID that has a resolving service to find associated metadata is also often described as an actionable GUID.

Refer to:

https://www.idigbio.org/sites/default/files/iDigBioGuidGuideForProviders_v1.pdf

A local resolver web service will:

receive web requests specifying a GUID;

search for the GUID in EMu modules;

and, if a match is found:

return metadata associated with the GUID.

The local resolver web service would query each EMu table containing GUIDs (determined by configuration settings). Alternatively, for improved query efficiency we may consider automatically populating a local table with all local GUIDs.

We stress that the mechanism is purely a web service – presentation logic will not be provided. Requests will be made of the web service using the http GET or POST protocols.

If we are engaged by an EMu customer to extend core EMu support to encompass other GUID schemes, then part of this work will be to extend the web resolver service to handle requests of the new GUID type.

To enable the local resolver web service, customers will need:

To install on a web server some lightweight IMu PHP code that accepts resolver web service requests and passes parameters through to the EMu server. This is simple setup and configuration on an existing web server. The web server and EMu server do not need to be the same host.

An IMu enabled EMu back-end environment that will be used to satisfy resolver web service requests and provide matching metadata (essentially this is enabling the imuserver background process in the EMu back-end).

To allocate one or more EMu licence slots for use by the resolver web service.

The resolver web service will provide functionality to:

Retrieve institution metadata describing the institution.

Search for a GUID and return matching status information and, if a match is found, return metadata about the match.

Metadata will be returned in XML format by default but can also be requested to be returned in JSON format.

Following are web service request examples using the http GET protocol and assuming the base web address of:

http://examplEMuseum.org/imu/guidresolver.php?

Retrieve host metadata:

request=info

Find a UUID returning data in XML:

request=find&guid=urn:uuid:84b567d5-dbbd-468a-be12-770747ebc397

request=find&

guid=urn:uuid:84b567d5-dbbd-468a-be12-770747ebc397&

format=xml

Find a UUID returning data in JSON:

request=find&

guid=urn:uuid:84b567d5-dbbd-468a-be12-770747ebc397&

format=json

Example of metadata from an info request returned in XML and JSON:

<?xml version="1.0"?>

<response>

<status>ok</status>

<id>YPMNH</id>

<museum>Yale Peabody Museum of Natural History</museum>

</response>

{

"status": "ok",

"id": "YPMNH",

"museum": "Yale Peabody Museum of Natural History"

}

Example of metadata from an unsuccessful find request returned in XML and JSON:

<?xml version="1.0"?>

<response>

<status>fail</status>

<guid>urn:uuid:84b567d5-dbbd-468a-be12-770747ebc397</guid>

</response>

{

"status": "fail",

"guid": "urn:uuid:84b567d5-dbbd-468a-be12-770747ebc397"

}

Example of metadata from successful find request returned in XML and JSON:

<?xml version="1.0"?>

<response>

<status>ok</status>

<guid>urn:uuid:84b567d5-dbbd-468a-be12-770747ebc397</guid>

<count>1</count>

<object>

<module>ecatalogue</module>

<irn>12345></irn>

<SummaryData>N 9837 Macropus rufus, South Eastern Australia</SummaryData>

</object>

</response>

{

"status": "ok",

"guid": "urn:uuid:84b567d5-dbbd-468a-be12-770747ebc397",

"count": 1,

"objects":

[

{

"module": "ecatalogue",

"irn": "12345",

"SummaryData": "N 9837 Macropus rufus, South Eastern Australia"

}

]

}